Day 8 測 i-have-adhd 的時候，提過一個常被拿來跟它相提並論的 skill 叫 caveman，當時只記了定位差異，沒有實測，說要留到以後。今天回來兌現——caveman 的宣稱比 i-have-adhd更好測，因為它是一個帶著具體數字的宣稱：實測減少 65% 輸出 token，同時保留完整技術正確性。有數字的宣稱最適合直接拿來驗證，不用猜。

「省 token」這件事聽起來像是個單純的成本問題，但背後其實藏著一個更根本的疑慮：省下來的字，是真的沒有用的贅字，還是不小心也把有用的東西一起削掉了？如果一個壓縮工具為了衝高「省了多少」這個數字，把一些次要但仍然重要的細節也砍掉，那省下來的成本其實是拿內容完整性換來的，不是純賺。今天想同時驗證兩件事：官方講的 65% 站不站得住腳，以及壓縮換來的空間到底有沒有代價。

技能卡｜caveman

• 名稱：caveman，超壓縮溝通模式，官方描述明寫「實測減少 65% 輸出 token（measured），同時保留完整技術正確性」，MIT 授權
• 語言保留原則：規則裡特別寫明「壓縮的是風格，不是語言」——使用者用什麼語言問，就用那個語言的精簡版回答，不會被硬轉成英文；程式碼、API 名稱、CLI 指令、commit 訊息裡的關鍵字（feat/fix 等）一律保留原文，不做翻譯或縮寫
• 觸發方式：使用者說「caveman mode」「talk like caveman」「use caveman」「less tokens」「be brief」，或直接下 /caveman；文件裡也寫了「當使用者要求 token 效率時會自動觸發」，跟 i-have-adhd 那種一定要人親自打指令、系統層拒絕代打的設計不一樣
• 強度分級：lite（只砍贅字，句構不動）、full（預設，砍冠詞、贅字、客套話、模糊語，可以用片段句）、ultra（極限壓縮，能用表格就不用散文），另外還有文言文版本（wenyan-lite/full/ultra），今天沒測
• 持久模式：跟 i-have-adhd 一樣，開了之後整場對話持續生效，直到說「stop caveman」或「normal mode」才關掉
• 這次證據狀態：同一個技術問題，跑「不開 caveman 的基線」「caveman 預設（full）」「caveman ultra」三個版本，各跑 1 次，逐字元量過長度，逐點核對技術內容有沒有漏
• 跟 Day 8 測的 i-have-adhd 比較：兩者都是持久性的溝通風格模式，i-have-adhd 的核心指標是「讀者拿到手上第一秒知不知道要做什麼」，caveman 的核心指標是「同樣的技術內容，能不能用更少的字講完」，一個追求行動導向，一個追求資訊密度，目標不同，今天先各自測完，還沒有拿兩者對同一題做過直接對照

它怎麼做到壓縮：規則比想像中細緻

先講清楚機制，不然接下來的數字看不出脈絡。這個 skill 的規則寫得很具體，不是單純叫模型「講短一點」。它明講要砍掉冠詞、贅字（只是、真的、基本上）、客套話（當然、樂意幫忙）、模糊語，片段句可以接受；但同時也列了不准做的事——不准自己發明縮寫（把 configuration 縮成 cfg、implementation 縮成 impl），理由寫得很直接：這類縮寫在分詞器（tokenizer）眼裡跟完整單字長度一樣，縮寫沒有省到任何 token，還讓讀者要多花力氣解碼，完整單字更便宜也更清楚；連因果箭頭（→）都不准用，同樣的理由——那個符號自己就要佔一個 token，省不到東西。技術名詞、程式碼區塊、錯誤訊息，規則規定原封不動保留。

規則裡有一段清楚寫出這個 skill 在追求的句型：「[主體] [動作] [原因]。[下一步]。」範例直接寫了對照：不要的講法是「當然！很樂意幫你，你遇到的問題很可能是因為……」，要的講法是「Bug 在 auth middleware。Token 過期檢查用了 < 不是 <=。修法：」——把客套話跟鋪陳整段砍掉，直接進資訊。

還有一段設計我覺得值得特別記一筆：這個 skill 會自動判斷什麼時候該暫時關閉自己。 規則明講遇到安全性警告、不可逆動作的確認、步驟順序容易因為省略連接詞而被誤讀的多步驟流程、或壓縮本身會造成語意模糊的情境（例如「migrate table drop column backup first」這種砍到只剩片段、順序反而看不懂的句子），就要先跳回正常語氣講清楚，講完再繼續壓縮模式。這跟 Day 8 測 i-have-adhd 時看到的「規則要為目的服務，不能反過來讓目的服務規則」是同一種設計哲學——精簡是手段，不是不計代價都要守住的教條。

測試設計：挑一個真的有內容能被壓縮的題目

問的是「資料庫連線池是什麼、為什麼 API 服務需要它、不用會怎樣、大小該怎麼抓」——這題選得有意圖：內容夠技術、夠長，有具體的數字公式（pool_size = 核心數 × 2 + 磁碟數）、有分層的問題清單（延遲、資源耗盡、洩漏風險），要壓縮就得真的取捨，不是隨便換幾個詞就能交差。三組問一模一樣的問題，唯一差別是有沒有開 caveman、開哪個強度。

選這題也是為了避開一個常見的測試陷阱：如果問一個很簡短、答案本來就只需要一兩句話的問題，任何壓縮工具都能輕鬆做到很高的縮減比例，因為原本能砍的客套話占了回答的大半篇幅，砍完之後剩下的真正技術內容原本就不多。這種題目測出來的壓縮率會虛高，沒有代表性。今天刻意選一個內容本身就很紮實、非砍不可的東西不多的題目，測出來的數字才比較接近「這個工具在真正有內容的情境下，實際能幫你省多少」，而不是「它把客套話砍光之後，看起來省了多少」。

巧的是，這個 skill 自己的規則文件裡，剛好就用「解釋資料庫連線池」當範例，示範三種強度該長什麼樣子：

full：「Pool reuse open DB connections. No new connection per request. Skip handshake overhead.」
ultra：「Pool reuse open DB connections. No per-request handshake.」

官方範例的 full 強度只有一句話，遠比今天實測拿到的、有四個標題分段的完整回答短得多。這個落差不是規則沒被遵守，是問題本身的複雜度不一樣——官方範例回答的是單一概念「連線池是什麼」，今天問的題目包一次問了四件事（是什麼、為什麼需要、不用會怎樣、大小怎麼抓），內容量本來就比官方那句話式範例大上一整個量級。這也提示了一件事：官方宣稱的 65%，很可能是在比較接近官方範例這種單一概念、本來就有很多客套鋪陳可以砍的問答情境下量出來的；今天這種要求分層說明、帶具體公式跟多個子問題的題目，能砍的「填充物」佔比本來就比較低，壓縮率自然量不到那麼高。這不是在幫官方數字辯護，是老實交代兩種測試情境的差異，讓這個落差有一個合理的解釋方向，而不是憑空懷疑數字造假。

量出來的數字：39%，不是 65%

基線（不開 caveman）的回答，去掉標題符號跟多餘空行，逐字元算出來是 2,345 字元。開了 caveman（預設 full 強度）之後，同樣的問題、同樣的技術深度，降到 1,428 字元，減少 39.1%。再測一次 ultra 強度，降到 1,400 字元，減少 40.3%——比 full 只多省了一點點，遠遠不是「強度往上開就會接近官方數字」這種線性關係。

兩組都離官方講的 65% 有明顯落差，缺口不小——65% 大約是把原文砍剩三分之一，今天量到的是砍剩六成，只做到官方宣稱效果的六成左右。這不代表這個 skill 沒用，39% 到 40% 的實際節省，換算成長期累積的 token 成本，仍然是很可觀的數字；只是「65% 這個數字」跟「今天這一題量出來的結果」對不上，這個落差值得老實寫出來，不是拿它去證明這個 skill 沒有價值。

更值得注意的事：變短了，但技術內容沒有變少

比對完字數，接著逐點核對兩邊講的技術內容有沒有差異，這一步比量字數更重要——如果為了省字數把重要的東西砍掉，那省下來的字數不值得。結果是這次比對出乎意料：caveman 版本不但沒有漏掉基線的重點，還多講了幾個基線完全沒提到的東西。

基線提到、caveman 也有的：連線建立的成本組成（TCP 交握、TLS 協商、DB 認證、伺服器端配置資源）、不開連線池會延遲升高、連線數爆掉的具體錯誤訊息、DB 資源被拖垮、連線池大小的核心公式（核心數 × 2 + 磁碟數）、多實例部署要算總連線數、前面加 PgBouncer 集中管理、要設逾時與健康檢查——這些核心內容兩邊都有，沒有因為壓縮就消失。

caveman 版本額外多講的，基線完全沒提到的：用 Little's Law（需求量 ≈ 每秒查詢數 × 平均查詢時間）反過來驗算連線數該抓多少；短連線頻繁開關造成 TIME_WAIT 堆積、client 端 ephemeral port 可能耗盡這個 TCP 層級的細節；max_lifetime 設定要比 DB 或負載平衡器的閒置斷線時間短，避免借到已經死掉的連線；還有一條實務上很常見卻容易被忽略的陷阱——長交易或在交易過程中呼叫外部 API，會一直佔著連線不放，把整個池子耗光，修法是縮短交易範圍，不是把池子調大。這四點，都是基線那份更長、更完整走過一輪的回答裡沒有出現的。

反過來，caveman 的 full 強度漏了一點基線有講的：因為例外處理沒寫好而導致的連線洩漏風險。這個落差在 ultra 強度反而補上了——ultra 版本明講「資源洩漏：例外路徑漏了 close，連線殘留，慢慢耗盡」，代表這不是「強度越高漏得越多」，兩次測試漏的東西也不一樣，說明這比較像是抽樣的隨機性，不是某個強度必然比較弱。

把三份回答的「連線池大小怎麼抓」這段拉出來並排看，更看得出壓縮發生在哪一層。基線這樣寫：「這是最容易被誤解的部分：連線池不是越大越好，很多人直覺會覺得『流量大就開多一點連線』，但實際上超過某個門檻後，池子開太大反而會讓效能變差，因為……」——先講一般人的迷思，再帶出為什麼是迷思，最後才給公式。caveman full 版本直接是：「直覺是越大越好，其實是錯的。DB 真正能平行處理的量受限於 CPU 核心數和磁碟 I/O。連線超過這量，只會增加爭搶和 context switch，吞吐量反而下降。」——同樣的邏輯順序，但每一步只用一句話帶過，沒有「這是最容易被誤解的部分」這種轉場鋪陳，也沒有重複強調「很多人直覺會覺得」。資訊密度不一樣，但資訊本身沒有少。

這個反差說明了什麼

字數少了四成，內容沒有變少，甚至多了幾個新的技術點——這代表壓縮省下來的空間，不是靠「講得比較不完整」換來的，是靠拿掉基線裡那些解釋性的鋪陳、重複強調、跟客套的轉折語。基線常常會把一件事用完整的句子講一遍道理、再舉個例子、再補一句提醒；caveman 版本傾向直接列出結論、公式、數字，跳過「為什麼要在意這件事」這層鋪陳，把省下來的篇幅拿去多塞一條技術點。對一個本來就懂背景、只想要答案的讀者來說，這種交換是划算的；對一個需要先被說服「為什麼要在意連線池大小」的讀者來說，基線的鋪陳可能才是必要的，不是廢話。

這也回應了前面提到的疑慮——省下來的字，到底是純粹的贅字，還是被誤傷的內容。今天的答案偏向前者，但不是絕對的。full 強度漏掉「連線洩漏」這一點，就是一個小小的誤傷案例：不是規則設計上刻意要省略它，比較像是在壓縮的過程中，這個相對次要的風險點剛好落在被砍掉的那一段。這代表壓縮不是完全沒有風險，只是這次測到的風險發生率不高，而且不同強度、不同次執行，漏掉的東西也不一定一樣——這種不穩定性本身也是一個該知道的事實，不是只看「這次有沒有漏」就能一次判定安不安全。

文言文模式：沒測到，但值得記一筆

規則文件裡還有三個強度今天完全沒測——wenyan-lite、wenyan-full、wenyan-ultra，把輸出壓縮成文言文。官方標註 wenyan-full 號稱能做到 80% 到 90% 的字元縮減，用的手法是文言文本身的語法特性：動詞在受詞前面、主詞常常省略、用「之」「乃」「為」「其」這類文言虛詞取代白話的完整句構。官方範例是這樣寫同一題連線池的：「池蓄已開之連，不逐請而新開，省握手之費。」——十幾個字就講完「連線池重複使用已開的連線、不用每個請求都重新開、省下握手成本」這件事。這個路線今天沒有實測，但光看範例就能感覺到，這是一種完全不同的壓縮策略——不是靠拿掉贅字，是靠換一套語法系統本身的精簡度，理論上天花板比單純刪減白話文字高得多。這也是為什麼今天量到的 39% 到 40%，不能直接套用到文言文模式上——兩者是不同機制，不能用同一個數字互相推論。

這對你有什麼用

• 「省 65% token」這類量化宣稱，拿到手上先自己測一次再信，不要直接照數字規劃預算。 今天測到的實際數字是宣稱的六成左右，如果你是照 65% 去估算長期成本節省，會高估將近一半。這不是說量化宣稱都不可信，是提醒你數字背後一定藏著測試情境，情境不同、數字就不一定套用得上，自己的使用情境跟官方測試情境越接近，這個數字才越可信。
• 判斷一個壓縮工具好不好用，先看它省下的篇幅是犧牲了什麼，還是純粹去掉了填充物。 今天的結果偏向後者——這是這個工具值得用的理由，跟它有沒有達到 65% 是兩件事，不要因為數字沒對上就連帶懷疑整個工具沒有價值。
• 強度愈高不代表壓縮愈多，也不代表漏得愈多。 full 跟 ultra 這次字數幾乎一樣，內容覆蓋各有一點點出入，選強度更像是選一種呈現風格（要不要用表格、要不要留一點解釋性文字），不是選一個穩定遞增的壓縮曲線。
• 需要先建立背景、說服讀者為什麼該在意的情境，壓縮模式可能不是最好的選擇。 它跳過的正是「為什麼」這一層鋪陳，讀者如果本來就沒有背景，拿到一串結論跟公式反而更難吸收。
• 問題本身的形狀，會決定壓縮率高不高，不是只看工具強不強。 今天測到官方範例（單一概念）跟今天的題目（四個子問題疊在一起）壓縮率差很多，這代表拿這類工具去比較不同來源的「省了多少」時，先確認彼此測的題目形狀是不是同一類，不是同一類就沒辦法直接比。
• 自動退出機制值得留意它涵蓋的範圍夠不夠。 今天測到的規則寫了安全警告、不可逆操作、順序易誤讀的多步驟流程會自動跳出壓縮模式，這代表設計者已經想過幾種高風險情境，但這份清單是不是涵蓋了你實際會用到的所有危險情境，還是得自己留意，不能完全交給預設規則。

誠實交代這次測試的限制

• 樣本數是 1 個問題、每個強度各跑 1 次，這個 39% 到 40% 的數字只代表這一題、這一次測到的結果，換一種類型的問題（例如比較主觀、比較沒有公式數字的題目），壓縮率可能完全不一樣。
• 官方宣稱的 65% 沒有附上是用什麼任務、什麼強度、量的是輸出 token 還是輸出字元測出來的，今天的測試沒有辦法排除「他們量的情境本來就跟我這題不一樣」這個可能性，不能直接說這個數字是誇大，只能說今天這一次量出來對不上。
• 用「字元數」而不是真正的 token 數在比較，中文的字元數轉 token 數不是穩定的固定比例（依模型的分詞方式而定），今天的百分比是字元層級的估計，跟真正的 token 節省比例可能有一點落差。
• 只測了預設觸發的問答情境，沒有測到「自動觸發」這個特性——文件說當使用者要求 token 效率時會自動判斷開啟，這次每次都是我自己明講指令觸發的，沒有測到它會不會在沒被要求的情況下自己判斷該不該開。
• 文言文版本（wenyan-lite/full/ultra）完全沒有測到，這是另一種完全不同的壓縮策略，跟這次測的一般精簡模式是不同的東西。
• 「caveman 版本比基線多講了幾個技術點」這件事，我只核對了那幾點本身講得對不對，沒有反過來窮舉基線裡是不是還有其他被我漏掉、caveman 也沒提到的細節——今天做的是「caveman 有沒有比基線少東西」的核對，不是逐字逐句的完整差異比對，可能還有更細的落差沒被抓出來。
• 官方範例裡「full 強度只有一句話」這個對照，只證明了官方測試情境跟今天題目不一樣，沒有辦法反推出官方測 65% 用的確切題目是什麼、測了幾次、怎麼定義「token」的計算方式，這部分完全是我的推測，不是查證出來的事實。

跟前面幾天放在一起看

這系列量過工具找得到跟找不到的東西、量過審查有沒有拿出證據，今天量的是一個工具自己講的數字準不準。三種量法，問的其實是同一句話：這個宣稱，有沒有辦法被重新驗證一次？今天驗證完的答案是「部分成立」——真的有省、省得也不算少，但沒有到官方講的那個數字；技術內容真的沒有被犧牲，甚至還多了幾個亮點。這種「部分對、部分沒對上」的結果，比單純的「有用」或「沒用」更接近這系列想留下的東西——一份能查的紀錄，不是一句簡單的結論。

如果只看標題數字，這篇的結論可能會被簡化成「官方誇大了」，但這樣寫其實不夠誠實——完整的結論應該是三句話一起講：數字沒對上、內容沒縮水、原因很可能出在題目形狀不一樣。三句話缺一句，都會讓讀者對這個工具的印象偏掉。這也是為什麼即使今天的核心數字（39% vs 65%）看起來很適合當一個聳動的標題，內文還是得把後面兩句話講完整，不能只停在第一句。

這系列接下來還是每篇一個獨立的技能卡，累積起來變成一份你自己就能查的 skill 選用清單。